Taking Initiative

When John, a senior backend engineer, noticed his company’s authorization service was experiencing intermittent failures during periods of peak loads, he could have simply logged a ticket with the service owner and moved on to his next task. After all, the failures weren't directly impacting his team's features, and he had plenty of assigned work to complete. But something about the pattern of failures nagged at John: the failures were predictable, as they occurred only under specific load conditions.

When he found some free time, John decided to investigate. He set up a test environment, and when he replicated the production load patterns, he discovered a race condition in the connection pooling logic. The bug manifested only when a particular combination of authentication requests hit the system simultaneously.

John showed the service team what he had found, and he suggested a possible solution. He did this collaboratively, not as someone intent on swooping in to fix their code. The service owner appreciated both John’s detective work and his respectful approach. Together, John and the service team designed a fix using a lock-free algorithm. Then they validated the fix with load testing simulating the identified failure scenarios. They followed this up by implementing monitoring that would catch similar issues before they could affect users.

Beyond simply the technical fix, John's initiative strengthened cross-team relationships. By investing time to understand a problem that wasn't affecting his team and approaching the owners collaboratively, he showed the kind of initiative that builds organizational trust. Other engineers began following this pattern, thus creating a culture in which people take action to help each other across team boundaries rather than simply filing a ticket and waiting for the next one.

What Does It Mean To Take Initiative?

A person with initiative asks clarifying questions to avoid building the wrong thing. They spot potential issues before they become critical problems, and they take action to develop solutions that aren’t yet on anyone else’s radar. This behavior can occur across all tech roles. For example, a data scientist identifies patterns in user behavior that nobody asked them to analyze, a product manager researches competitor features without being prompted, or a backend engineer refactors shared code that they can see will lead to a bottleneck before a problem is reported.

Big tech companies have codified this competency into their core values and hiring practices. Amazon calls it "Bias for Action." They value people who understand that speed matters in business and will act despite the presence of ambiguous information. Netflix's "Freedom and Responsibility" culture explicitly encourages and expects employees to make decisions and take action without waiting for approval. Stripe looks for people who "move with urgency and focus" and solve problems before they're asked. These companies understand that waiting for direction or perfect information can lead to missed opportunities. And, more often than not, small problems will become big ones if they are not acted upon early and urgently.

The Essence of Taking Initiative

Whatever the workplace, you will always have moments when you see something broken, but it isn't your problem. What you do next defines initiative, or not. You could ignore it, log a ticket, mention it in standup, or just work around it like everyone else has been doing for weeks, months, or years. Or you could decide to fix the problem, even though you didn’t have to. Initiative lives in the choice you make to extend beyond your assigned responsibilities.

There is often a critical tension to manage when deciding to take initiative. You need to judge if it would be okay to act independently or whether it would be better to seek permission first. Initiative without this judgment leads to chaos. On one hand, imagine what would happen if everyone simply fixed what they thought was broken without coordinating their actions with anyone else. But, on the other hand, if everybody had to wait for permission before doing anything, that would result in stagnation.

Good initiative means discerning which problems you can and should solve independently, while respecting boundaries and priorities.

Initiative differs from the concept of ownership, but the two are often conflated. Whereas ownership means taking responsibility for outcomes within one’s assigned scope, a person with initiative identifies work outside their immediate area of work and chooses to do it.

You can have strong ownership of your assigned projects and do your job perfectly without ever exercising initiative. But if you solve a problem you don't own, for example, you fix issues with software that belong to different teams, that’s initiative.

Cultural and Organizational Considerations

How an organization values and expresses initiative will depend on its context and the constraints within which it operates. Some companies see initiative as essential for success, while others prefer that their employees stay within defined boundaries.

Cultural Background Considerations: Cultural backgrounds affect how people view initiative. In some countries, doing work beyond what you're explicitly asked to do can be seen as overstepping or disrespectful to authority. If you come from a culture that places greater value on following instructions precisely and you are more comfortable working in that manner, you might need to reframe your experiences through related competencies such as Delivery or Problem-Solving that show value within assigned work.

Startups and High-Growth Companies: Initiative isn't just valued in these types of companies, it's also expected. If you cannot show an ability to use your initiative, that is a red flag. Startups and companies in high-growth mode need people who are happy wearing multiple hats and who will identify and fix whatever problems are blocking progress without waiting for permission. The risk tolerance in these work environments is high, as it's better to fix something imperfectly than leave it broken.

Large Tech Companies: These companies value employees who take initiative in identifying areas where ownership is lacking, but they also want employees who will do the right thing. They want people who seek to improve systems and processes but who also respect existing ownership. Initiative in a large tech company usually boils down to knowing when you should build consensus to develop solutions and when it’s acceptable to go it alone. The most valued skill is knowing how to improve things without breaking what's already working, even when the org chart makes that hard to do.

Traditional Enterprises and Regulated Industries: These types of organizations approach initiatives more carefully. They value people who can identify opportunities for improvement but will work through the proper channels to implement solutions. Initiative might mean formally proposing process improvements or building proofs-of-concept that show value before seeking broader changes. The priority is reducing risk and making sure that any changes that are introduced won't disrupt critical systems or processes.

Consultancies and Agencies: Initiative in consultancies and agencies means identifying ways to add value beyond the stated scope of engagement. Examples of this sort of initiative include delivering more than what was expected in targeted areas, documenting patterns that will help the client after you leave, or building tools that will make their future work easier.

The Work Hours Question: A Matching Perspective

A common question that many candidates struggle with is whether they should talk about working nights and weekends. The answer for you will depend on whether this reflects your actual work style and the type of culture you're targeting.

Some companies, particularly startups and high-growth organizations, actively seek people who will go all out when they encounter important problems. Those types of companies value intense dedication, and they view regularly working extra hours as a sign of commitment and passion. On the other hand, companies that prioritize sustainable work practices will tend to view regular overtime as a red flag, potentially indicative of poor planning, slow execution, or an inability to set boundaries.

Neither approach is inherently right or wrong. They're simply different cultures and approaches to working that suit different people. Some professionals thrive on periods of intense work, and they will see their willingness to work nights and weekends as a competitive advantage. Others establish boundaries around work hours, whether due to personal values, family responsibilities, or simply knowing what maintains their long-term effectiveness. Both types can be excellent employees in environments that are right for them.

If you regularly work extra hours on projects and view this as a strength: Be explicit about it in your stories. Frame it as a deliberate choice that reflects your commitment and work style. Companies that value this will see it as a strong positive signal. Companies that don't value it are probably not places where you'd thrive anyway, so it's better to learn this before you decide to apply, or at the very latest, during the interview process.

If you prefer strong boundaries: Frame your answer to the initiative question around your ability to select the “right” problems to solve and your habit of working effectively and efficiently within normal hours. Emphasize how you regularly identify high-impact problems that don't require heroic effort to solve. If you have worked extra hours, be clear that it was a rare exception during a genuine crisis and not your regular pattern.

If you occasionally work extra hours during critical situations: Frame these instances clearly as deliberate responses to specific circumstances, not as your default approach. Explain what made the situation critical and why extra time was the right choice.

The worst outcome is accepting a role at a company whose expectations don't match your work style. Use your stories to show how you actually approach work, and let companies self-select based on whether that fits their culture.

Related Competencies

Initiative vs. Delivery: These competencies complement each other while focusing on different aspects of performance. Initiative is about choosing to work on unassigned problems, for example, deciding to fix an issue of your own accord. Delivery means successfully completing work despite the presence of obstacles; for example, you make a fix that unblocks critical workstreams.

Initiative vs. Problem-Solving: A person who is good at problem-solving has the ability to fix complex issues through investigation and analysis. Initiative is about choosing which problems to solve without being asked. Your manager might assign you a tricky performance bug (problem-solving), or you might notice that performance is degrading and decide to investigate the problem without being asked (initiative leading to problem-solving). Many stories combine both qualities (e.g., you take the initiative to investigate a problem, then you apply your skills to fix it).

Interview Questions

Interviewers approach the question of initiative from multiple angles to understand whether or not you actively identify and pursue opportunities beyond your assigned tasks. They want to distinguish between someone who works hard only on tasks they are given (good) and someone who also finds new problems to solve (even better).

While interviewers may explore all these angles, you should focus your preparation on two critical areas: (1) identifying unassigned problems, and (2) deciding to fix them if appropriate. These core signals matter the most. If you're struggling to find examples covering every category below, prioritize stories that clearly show you spotting opportunities nobody asked you to pursue and choose to take them on after judging that it would be appropriate for you to do so. The other categories support these core signals, but it is not essential to include them in your story if your primary examples are strong.

Going Above and Beyond

• "Tell me about a time you went above and beyond your assigned responsibilities."
• "Describe a situation where you took on something significant outside your area of responsibility."
• "Give me an example of work you did that nobody asked you to do."

These questions directly probe whether you choose to do more than is required of you. Interviewers want to know if you typically spot and pursue opportunities or only act when and where directed. Good stories are clear about what was assigned to you versus what you chose to take on, and why you decided to step outside your lane.

Spotting Problems Early

• "Tell me about a time you identified and solved a problem before others noticed it."
• "Describe a situation where you prevented an issue from becoming a major problem."
• "How do you spot risks or opportunities that aren't on anyone else's radar?"

The interviewers want to see if you notice problems early and act on them. They're also testing how you balance such work with your assigned responsibilities. Good answers are the ones that describe finding time during lighter sprint weeks, negotiating with your manager to allocate capacity, or identifying quick wins that don't require significant time investment. How you frame extra hours matters, and what works depends on the culture you're seeking (see previous section: The Work Hours Question). The key is authenticity: better to find a company that values your actual work style than to hide it and end up in a poor cultural fit. Strong stories will tell of how you spot early warning signs, make smart decisions about when to invest time, and fix things before they get worse.

Making Things Better

• "Give me an example of a process, system, or product you improved without being asked."
• "Tell me about something you improved even though it was working adequately."
• "Describe a time when you anticipated future growth or change and prepared a solution to accommodate it."
• "Give me an example of when you fixed something before it became a problem."

Interviewers will evaluate whether you look for ways to improve things or tend to accept the status quo. Strong responses show you questioning why things work the way they do and investing the effort to create improvements, even if the existing solutions are functional.

Acting Independently

• "Describe a time when you made a decision independently and informed your manager afterward."
• "Have you ever started a project without first receiving formal approval or resources?"
• "Give me an example of when you took action despite unclear requirements."

These kinds of questions are posed to probe your judgment about when to act independently versus when to seek guidance. Note that "acting independently" doesn't mean hiding what you're doing or making important decisions in isolation. Strong answers show you taking action while keeping stakeholders informed, not necessarily asking for permission at every step, but also not surprising people with major changes. This distinction is important because good initiative builds trust through transparency.

Taking Smart Risks

• "Tell me about a calculated risk you took on unassigned work."
• "Describe a time when your initiative didn't work out as planned."
• "How do you decide whether or not to pursue an opportunity nobody has asked for?"

These questions examine how you evaluate whether or not unassigned work is worth pursuing. Interviewers want evidence that you will think through the implications before acting and will learn from both successes and failures in taking initiative.

Key Signals

When evaluating your strengths in relation to initiative, interviewers will look for evidence that you will act on identifying and addressing unassigned problems rather than doing the work you’re given and nothing more. The strongest candidates show a pattern of finding opportunities and acting on them with good judgment.

Critical Signal: The Proactive Decision

The moment you consciously choose to act on an unassigned problem or opportunity defines initiative. The heart of it is recognizing that something needs attention and deciding to be the person who addresses it. Strong stories will capture this decision point explicitly. For example, "I noticed X happening and realized that Y would soon cause trouble if the problem wasn’t addressed now. Although it wasn't my responsibility, I decided to investigate, because Z." The critical element is showing you made a deliberate choice to go beyond your assigned scope, not that you stumbled into extra work or were “voluntold” to help.

Critical Signal: Acting While Communicating

Taking initiative doesn't mean working in isolation or asking permission at every step. You might tell your manager, "I noticed this issue affecting three teams and I'm investigating the root cause this week," rather than asking them, "Should I look into this?" When making decisions that affect others, or when touching shared systems, you communicate your plans to the affected people while you are already working on the solution (e.g., "I'm building a fix for the race condition. I will share a demo with you on Friday.") This approach shows you employing initiative through action and, at the same time, building trust through transparency.

Strong Signal: Seeing Patterns Others Miss

People with strong initiative look past the obvious. They notice recurring pain points, anticipate bottlenecks, and spot patterns others miss. Examples include identifying systemic issues by analyzing isolated incidents, recognizing when small inefficiencies compound into major problems, and spotting opportunities in adjacent areas that could benefit your team.

Supporting Signal: Follow-Through to Impact

Many people notice problems, but not many will fix them without being asked. Communicating this signal shows the interviewers that you push through obstacles, find resources, and influence others to adopt your solutions, and that you are comfortable doing this without formal authority or assignment. The key is that you drive these initiatives to completion; you don’t just raise them as questions for others to solve. When you identify a problem that you can tackle, you own it through to impact, although you may involve others strategically along the way. You measure the results and you iterate based on feedback.

Red Flags

In this book, we use Red Flags to denote serious issues that will significantly damage your candidacy and Yellow Flags for concerning patterns that will weaken your examples.

Many candidates hurt their chances by confusing related behaviors. If you understand these common mistakes, it will help you focus your stories on what’s important.

Red Flag: Working Hard on Assigned Tasks

If you mistake hard work for initiative, your stories will tell the interviewers that you don't understand what they’re looking for. Doing assigned tasks really well is good performance, not initiative. Working nights and weekends on your assigned project doesn't demonstrate initiative; it shows diligence and commitment.

Note: This flag is about confusing hard work with initiative, not about working extra hours per se. If you regularly work nights and weekends on unassigned problems that you identify and choose to pursue, that's genuine initiative. But don’t mistake "I worked really hard on my assigned project" for "I proactively took on unassigned work." Whether unassigned work happens during regular hours or extra hours is a separate question of cultural fit.

Initiative means finding and fixing problems nobody asked you to solve. Therefore, focus only on work you chose to take on, not work you did exceptionally well.

Yellow Flag: Acting Without Thinking

Tackling work without considering why it hasn't already been assigned suggests poor judgment. Maybe another team owns it for good reasons. Perhaps your manager skipped over it due to other priorities. Or the work needed context that you don't have. Good initiative stories show you thinking through these factors first because they show that you understand not only technical matters but also how organizations work.

Yellow Flag: Missing the "Why" Behind Your Initiative

Starting your story with what you did without first explaining why you chose to act can make your exercising of initiative seem random. Interviewers can't assess your judgment about unassigned work if they don't understand what motivated you to take it on. Therefore, take the time in your story to describe how and why the specific problem caught your attention: what patterns you saw; why nobody else was addressing the problem; and what would happen if you didn't act. Supplying this context will show that you choose your battles wisely, rather than randomly taking on extra work.

Yellow Flag: Playing the Lone Hero

Telling a story that has you single-handedly identifying and solving everything will likely raise eyebrows, because a story like that misses how exercising initiative typically succeeds in organizations. Stories that focus only on individual action will suggest to interviewers that you may have a tendency to pursue pet projects without considering organizational needs. Even self-directed work needs buy-in. You need to obtain validation that the problem indeed exists, get input on potential solutions, and you may need to influence others to adopt the solution you develop. Show how you took action while keeping it aligned with what the organization actually needed.

Yellow Flag: Being Vague About Value

Saying that your self-directed work "helped the team" without proving its worth will make your interviewers wonder whether your initiative created real value or just kept you busy. They need to hear evidence that your choosing to work on an unassigned problem was the right decision. Include specific outcomes. How much time did you save by preventing future problems? What errors were avoided? Did your colleagues adopt your solution? Providing such concrete results will help to justify why your taking initiative was better than focusing only on your assigned work.

The examples below show initiative at different levels. The scope gets bigger as you go up, but the pattern is the same: spot something unassigned, choose to act, and follow through.

Example Stories by Level

Entry-Level Example: Automation Initiative

Question: "Tell me about a time you went above and beyond your assigned responsibilities."

Headline: "Earlier this year, I automated our release verification process after noticing our team spent hours on manual checks. My solution reduced deployment time from 3 hours to 10 minutes."

Key Point 1: "Every release required someone to manually verify 15 different API endpoints and check database migrations. Our whole team rotated this duty, and it took about 3 hours each time. After doing these checks a few times, I realized we were wasting engineering time on something a computer could do. Even though I was hired to work on the frontend, I decided to build an automation tool during a lighter sprint because I saw how much time it was wasting across the team."

Key Point 2: "Before diving in, I checked with my tech lead about spending time on this automation. I showed him my rough calculations of time saved and asked if it was okay to work on this during our lighter sprint week. He was actually thrilled someone was thinking about developer productivity. I also checked with our DevOps team since the tool would interact with our deployment pipeline. They gave me guidelines about which systems I could safely automate versus what needed to stay manual for security reasons. This upfront agreement meant I didn't waste time building something that wouldn't be allowed in production."

Key Point 3: "I spent a week building a verification script. But I didn't stop at basic functionality. I added clear error messages, handled edge cases for flaky services, and created documentation so anyone could run it. When I showed it to my manager, I showed data from our last five deployments. We'd spent 15 hours on manual checks that my tool could complete in 10 minutes. The team adopted it immediately."

Landing: "My automation tool saved about 12 hours of engineering time per week and made deployments less stressful. The team started deploying more frequently since the overhead was gone. I now constantly scan for repetitive tasks that waste engineering time, but I always check with stakeholders before automating anything that touches shared systems."

Mid-Level Example: Performance Investigation

Question: "Give me an example of work you did that nobody asked you to do."

Headline: "Here’s one. A couple of months ago, I investigated dashboard performance during a customer demo and discovered query problems that would have likely cost us major deals with bigger clients."
Key Point 1: "During a sales demo, I noticed our analytics dashboard took 30 seconds to load for a prospect with lots of data. Sales smoothly talked through the delay, but I knew this customer had 10x more data than our typical clients. We had 5 similar large deals coming through our pipeline. Even though performance optimization wasn't on anyone's radar, we had a huge backlog of feature requests. I decided to investigate because I could see this becoming a deal-breaker for bigger customers."

Key Point 2: "First, I spent a few hours investigating on my own to understand the scope of the problem. Once I confirmed the performance would be completely unacceptable for larger customers, I had to decide how to proceed. I could have just optimized the queries myself, but this touched our core analytics engine, which was owned by another team. So I put together a one-page analysis showing the performance cliff we would most likely hit with larger customers and scheduled time with both my manager and the analytics team lead. They were grateful I'd done the initial investigation and immediately made it a priority."

Key Point 3: "My manager said she appreciated that I'd gathered data before escalating, but she initially stated that the backlog was more important. She changed her mind after I simulated that the page load time would spike to 5 minutes with just 50% more data. With official support, I spent a week building a proof-of-concept that added intelligent caching. I worked closely with the analytics team to ensure my changes aligned with their architecture. Load time dropped from a projected 5 minutes to 8 seconds. Because I'd involved the right people early, we could implement it properly without territorial conflicts."

Landing: "The optimized dashboard eliminated a potential roadblock for larger deals. We went on to close three major contracts worth about $2M total, whose evaluation criteria specifically included performance. Now I always do initial investigations to scope problems before escalating, but I involve the stakeholders before making changes to shared systems."

Senior-Level Example: Cross-Team Monitoring System

Question: "Describe a situation where you took on something significant outside your area of responsibility."

Headline: "Okay, this is a good one. Last year, I fixed our team's production monitoring issues in a way that ended up helping other teams with similar problems."

Key Point 1: "Our team was averaging a production incident per week, and every debugging session started with 30 minutes of hunting through logs. As team lead, I was responsible for improving our operational efficiency. I started by focusing on our immediate needs, but as I talked to other team leads, I realized the commerce team and data team were fighting the same monitoring problems. I decided to build our solution in a way that could potentially help others, too."

Key Point 2: "As a senior engineer, I had autonomy to improve our team's monitoring without asking permission. But when I realized the solution could help others, I had to be careful about expansion. I built our team's monitoring first, proving it worked with real results. Then, instead of just pushing our solution on other teams, I presented our approach at the engineering all-hands and invited interested teams to a follow-up discussion. Three team leads attended, and we collaboratively adapted the framework for their needs. This opt-in approach meant teams felt ownership rather than having a solution forced on them."

Key Point 3: "I made the monitoring components reusable and documented our patterns. When the commerce team lead asked how we'd improved our incident response time, I offered to help them adopt similar monitoring. Because I'd designed the original dashboard to be reusable, they could implement a plug-in in about an hour rather than building theirs from scratch. By positioning it as sharing rather than prescribing a solution, I achieved enthusiastic adoption. Each team made their own improvements, which we incorporated back into the shared framework."

Landing: "Our team's incident response time dropped from 45 minutes to about 15. Within four months, three other teams had adopted similar monitoring approaches, and their response times improved as well. "

Staff-Level Example: Service Resilience Patterns

Question: "Tell me about a time you identified and solved a problem before others noticed it."

Headline: "Probably my best example was when I discovered failure patterns in our search service that revealed broader resilience issues across our platform."

Key Point 1: "While investigating why our search index query latency had degraded during a recent incident, I noticed something concerning. The root cause was a slowdown in our user service, but the search service had made things worse by aggressively retrying failed requests. I dug into our data and found this same pattern in 70% of major outages. Small problems in one service triggered cascade failures of others. Nobody was looking at this pattern because each team focused only on their own services."

Key Point 2: "At the staff level, I had broad autonomy to identify and solve platform-wide issues. But resilience patterns would require every team to change their services, and I knew that asking 20 teams to each implement circuit breakers and retry budgets individually would take a year and produce 20 inconsistent implementations. So after proving the fixes worked in the search service, I took a different approach. I partnered with our platform infrastructure team and proposed that we build these resilience patterns directly into our shared service framework. If we got it right, teams would get circuit breakers, jitter, retry budgets, and graceful degradation by default just by upgrading to the latest framework version, without code changes or big forced migration projects that needed to be prioritized."

Key Point 3: "The platform team and I spent three weeks building the resilience layer into the framework. The tricky part was getting the defaults right, because if you’re too aggressive on circuit breaking, you'll cut off healthy traffic. Too lenient, and you won’t prevent cascading failures. We tested against recordings of our five worst outages to calibrate the thresholds. Then we rolled it out to the search service and the commerce service as early adopters. When the next incident hit, both services degraded gracefully instead of amplifying the failure. That gave us the confidence to ship the new framework version org-wide."

Landing: "Over six months, seven teams implemented these resilience patterns, and cascade failures dropped by about 80%. What used to be platform-wide outages now only manifests as isolated service degradations. Now I systematically review our incident data every quarter, looking for patterns that cross team boundaries."

If Examples Don't Come Easily

Think about the last time you saw something working adequately but inefficiently and decided to improve it. Such moments of choosing to make things better when nobody asked often make the best subjects of initiative stories.

Look for the exercising of initiative in the margins of your assigned work. If you have ever automated a task that wasn't broken but was inefficient, that was an initiative, even if it only saved 30 minutes a week. Have you ever written documentation simply because you got tired of answering the same questions? Initiative again. Identifying and solving unassigned problems. Have you ever refactored code during a feature implementation because you saw a better pattern? If the refactoring went beyond the feature requirements, you guessed it: initiative.

Reflection Questions:

Use these prompts to identify examples of initiative from your experience. You don't need examples for every question. Two or three strong stories covering different aspects of initiative will serve you well in interviews.

• When have you noticed something inefficient and fixed it without being asked?
• What recurring problems have you solved that weren't technically your responsibility?
• Have you created tools, templates, or automations for tasks that were functional but tedious?
• When did you improve documentation, runbooks, or processes beyond project requirements?
• What knowledge gaps have you identified and filled before they caused problems?
• Have you streamlined communication between teams that weren't coordinating well?
• When have you researched new methods or tools that could help your team work better?
• What manual processes have you improved even though nobody has complained about them?
• Have you identified and fixed data quality issues before they began to impact decisions?
• When did you create resources that helped others onboard or work more effectively?

Key Takeaways

An interview is the means by which you (and the company) try to determine whether you would be a good match. Use your initiative story to signal your authentic work style, and you will increase your chances of finding companies where you'll thrive.

Strong Initiative Stories Include:

• A clear moment when you chose to act on something unassigned.
• Evidence that you thought through why the work hadn’t already been assigned.
• Appropriate judgment about when to act independently vs. seeking permission.
• Specific outcomes that justified your taking on unassigned work.
• Learning about when and how to take initiative in the future.

Avoid These Traps:

• Don't confuse working hard on assigned tasks with taking initiative.
• Don't present acting without thinking as initiative. Show them your judgment.
• Don't focus only on your individual actions. Show how you involved others appropriately.
• Don't be vague about the value that was created. Include the specific outcomes.
• Don't confuse natural growth with initiative. Show your specific contribution beyond what would have happened anyway.